This icon file is displayed differently when used as ZulipIcon. In the file, the head section is an outlined circle, but in the app, it is a filled circle.

Yeah, fill-rule="evenodd" doesn't work when converted to a font. Here's instructions for fixing it:
https://zulip.readthedocs.io/en/latest/subsystems/icons.html#correcting-icons-with-an-evenodd-fill-rule

Interesting; the ValueChanged typedef was new to me!

I think a different approach would be worthwhile, though, toward more familiar/transparent state management and to minimize added code in _MessageListPageState.build.

• On MessageListPageState, add methods like the following:

  /// The "revealed" state of a message from a muted sender.
  ///
  /// See also: [revealMutedMessage], [unrevealMutedMessage].
  bool isMutedMessageRevealed(int messageId);
  
  /// For a message from a muted sender, reveal the sender and content,
  /// replacing the "Muted sender" placeholder.
  void revealMutedMessage(int messageId);
  
  /// For a message from a muted sender, hide the sender and content again
  /// with the "Muted sender" placeholder.
  void unrevealMutedMessage(int messageId);

• Implement these in _MessageListPageState, backed by a Set of message IDs. The implementations should be simple and don't need to involve the store or any event handling; just simple add/remove/read.

• Read the dartdoc on MessageListPage.ancestorOf and the implementation comment under it. Since we'll need to call this from a build method, make a prep commit that creates an InheritedWidget, so that ancestorOf can become something like:

    /// The [MessageListPageState] above this context in the tree.
    /// 
    /// Uses the efficient [BuildContext.dependOnInheritedWidgetOfExactType],
    /// so this may be called in a build method.
    static MessageListPageState ancestorOf(BuildContext context) {
      final state = context
        .dependOnInheritedWidgetOfExactType<_MessageListPageInheritedWidget>()
        .state;
      assert(state != null, 'No _MessageListPageInheritedWidget ancestor');
      return state!;
    }

  Ah—in fact I think it might need to be an InheritedNotifier, with the reveal…/unreveal… methods calling notifyListeners, so that widgets update when isMutedMessageRevealed has a new value?

• HideMutedMessageButton (perhaps renamed UnrevealMutedMessageButton for consistency) can just do this in its onPressed:

  MessageListPage.ancestorOf(pageContext).unrevealMutedMessage(message.id);

• The "Reveal" button in the message list can do this:

  MessageListPage.ancestorOf(context).revealMutedMessage(message.id);

• And the UI state in _MessageWithPossibleSenderState.build can use MessageListPage.ancestorOf(context).isMutedMessageRevealed.

Implement these in _MessageListPageState, backed by a Set of message IDs. The implementations should be simple and don't need to involve the store or any event handling; just simple add/remove/read.

I started to refactor the code based on the suggested changes, but it's getting complex; maybe I am not doing it the right way. Also, I think we still need store to react to live changes via MutedUsersEvent.

I see; yeah, I'm running into trouble with the InheritedNotifier approach too. I'll see if I can make something else work.

This feels verbose; how about just "Reveal message"? The sender row already says "Muted sender".

How about "Muted user"? The fact that it's the sender is already communicated by the position of this text.

I think "Muted user" is better for the reason you mentioned, and I think Web should also consider using this phrase in #34794.

Ooh good thought; I've left a comment there. Thanks for noticing!

msglist: Distinguish messages sent by muted users

Commit-message nit: no Fixes: line until a later commit, when all of the issue's work is done :)

If all callers pass size, let's make it required

What's the meaning of the size param, and why isn't it used directly here? When I read this I wonder why callers don't just pass the size they want (e.g. from a Figma frame) and expect it to be applied faithfully :)

Ah I think I see: size is really about the dimensions of the square gray box, and the icon is meant to be some fraction of that, right?

Oh, but a nuance: the actual size of the box is controlled by AvatarShape, which callers are supposed to use as a wrapper. So I think the size param calls for a dartdoc explaining why it's needed; something like:

  /// The size of the placeholder box.
  ///
  /// This should match the `size` passed to the wrapping [AvatarShape].
  /// The placeholder's "person" icon will be scaled proportionally to this.

Then here, on the arithmetic, an implementation comment like:

        // Where the avatar placeholder appears in the Figma,
        // this is how the icon is sized proportionally to its box.

Ah, these aren't Figma design variables in the usual way—

—they're part of a "color palette" (see #831).

Since the Figma doesn't seem to offer a variable, let's first see how these look in dark mode (please post screenshots); if they look reasonable (even if not perfect), I'd just hard-code the colors inline, with a TODO(design): dark-mode variant?. If we need a dark-mode variant, please @-mention Vlad in #mobile.

I think these colors should look good in dark mode too, but for some reason, they don't. In dark mode, these colors seem to be changing, even though we use the same colors for the two modes in theme.dart.

Light	Dark

Looking at #831, which will pull those colors automatically, should we remove them from theme.dart and use them inline for now?

Does it look OK if we use listMenuItemBg for the rounded-rectangle background and listMenuItemIcon for the person icon? With a TODO in the widget code like:

// TODO(design) this was ad-hoc, we need a new variable

Here they are in a screenshot from the Figma:

Here are the hex values (from hovering over where it says grey/200 etc.):

This would mean adding listMenuItemBg and listMenuItemIcon to DesignVariables. It does seem like we can't use the same color for both light and dark theme, and that means we have to use DesignVariables, which enables the smooth animation between light and dark theme.

These look fine on both modes.

Light	Dark

But what about using groupDmConversationIconBg and groupDmConversationIcon instead? They also appear in recent DMs page together.

That does seem like a better fit! Thanks for finding those. Since those aren't named variables from the Figma—they're in the section with the comment

  // Not named variables in Figma; taken from older Figma drafts, or elsewhere.

—we're free to name them however we want. Could say avatarPlaceholderIcon and avatarPlaceholderBg; I think that would fit these new uses as well as the existing use on the recent-DMs page.

Pushed with these new changes.

With 20+ lines of code, this would be good to pull out into a separate widget or a helper method

nit: how about "Text to display in place of a muted user's name"

(I think "all over the app" isn't very actionable for translators; the important thing is that it replaces strings like "Chris Bobbe", "Greg Price" etc.; it doesn't matter as much that those strings appear all over the app)